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ABSTRACT 

The thermal vacuum facilities located at the Goddard Space Flight Center (GSFC) have supported both 
manned and unmanned space flight since the 1960s. Of the eleven facilities, currently ten of the systems 
are scheduled for refurbishment or replacement as part of a five-year implementation. 

Expected return on investment includes the reduction in test schedules, improvements in safety of facility 
operations, and reduction in the personnel support required for a test. Additionally, GSFC will become a 
global resource renowned for expertise in thermal engineering, mechanical engineering, and for the 
automation of thermal vacuum facilities and tests. 

Automation of the thermal vacuum facilities includes the utilization of Programmable Logic Controllers 
(PLCs), the use of Supervisory Control and Data Acquisition (SCADA) systems, and the development of a 
centralized Test Data Management System. These components allow the computer control and automation 
of mechanical components such as valves and pumps. The project of refurbishment and automation began 
in 1996 and has resulted in complete computer control of one facility (Facility 281), and the integration of 
electronically controlled devices and PLCs in multiple others. 


INTRODUCTION 

The thermal vacuum lab at Goddard Space Flight Center consists of nine (9) thermal vacuum chambers in 
Building 7 and one (1) thermal vacuum chamber in Building 10. The chambers in Building 7 range in size 
from 2’x2’ to 12’xl5’ and are situated in an area covering approximately 7,000ft 1 2 . Command and control 
for these facilities is performed by an operations crew, numbering two to four, at various locations within 
this area, and on two different floor levels. Facility 290 in Building 10 is a 27’x40’ vertical chamber that is 
controlled by a separate operations crew that is also positioned on two different floor levels. 

Each chamber averages approximately 3,000 to 4,000 operational hours per year. This volume of work, 
coupled with the dispersion of the control systems, results in a large operational workload for the facility 
operators. One main objective of this project is to provide the operations personnel with the technology to 
more easily manage the amount of work that exists at any given time. In addition, it is also desired to 
provide real-time access of current as well as archived test data to experimenters in multiple locations. 
This paper is an update of the progress made to date, with the focus on the new data acquisition system and 
its expanded role in the overall system. 


PROJECT GOALS 

There are five main objectives that this program is intended to address: 

1. Centralized command and control capability. 

By positioning the facility controls in a centralized location, the capacity of the operations staff is 
effectively maximized without increased risk. This implies replacement of most manual controls with 
computer based operation. 



2. Greater testing flexibility 

The ability to alter data presentation to the operator or customer is highly valued, but very laborious if not 
built in from the beginning. Custom screen development without the need of a programmer was a top 
requirement for the new system. 

3. Improved data accessibility 

The current thermal vacuum data system stores data in a binary format on a proprietary Hewlett Packard 
network. HP no longer supports this network, and data retrieval from the archival media is quite tedious. 
The new system seeks to make test data readily available to anyone with a network connection. 

4. Increased payload and personnel safety 

By providing the facility operators with real-time access to all critical chamber and payload parameters, 
payload safety is inherently increased. In addition, by making the information available to the operators at 
a single site, personnel safety is improved as well. 

5. Overall reduced testing costs and improved performance 

The net result of these cumulative efforts will be a more efficient and effective laboratory operating at a 
higher performance level. 


DESIGN PHILOSOPHY 

A new approach was taken in the design for the laboratory. Once entirely separate entities, the facility 
command and control now interfaces with the payload data acquisition system. Command and control is 
still exclusively handled by the Programmable Logic Controllers (PLCs) and associated SCADA software, 
however, for some tasks the PLC actually receives inputs from the data system side of the project. A top- 
level functional diagram is shown below: 
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DATA SYSTEM 

For the purpose of this discussion, the new data system can be divided into three main subsystems; the 
Oracle Database Engine, External Interfaces, and the PowerBuilder Interface. 

Oracle Database Engine 

The core of the new data acquisition system is the Oracle Database Engine. The Oracle Database Engine 
was selected for its inherent flexibility and power. Oracle easily handles our data storage requirements and 
provides a powerful scripting tool. The database table structure includes support for alarms, custom client 
display definitions, data acquisition commands, security, test data storage/retrieval, and chamber 
automation. Database tables are normalized by the use of primary and foreign keys. A timestamp, tagname 
and test number uniquely identifies test data. Data acquisition, alarming, calculations and chamber 
automation are accomplished through the use of Oracle stored procedures and triggers. Stored procedures 
and triggers provide consistent application of business rules and a single point of maintenance. The use of 
Oracle transforms the data system into a Test Data Management System rather than just a mere data 
acquisition system. 


External Interfaces 

SCADA to HP3852A: Facility and payload thermal data is acquired by HP3852A-Data Acquisition units 
located throughout buildings 7 and 10. The HP3852A’s are remotely interfaced to SCADA by the 
HP2050A LAN to IEEE-488 Gateway. The HP2050A allows remote operation of IEEE-488 instruments. A 
custom C language SCADA program was developed using the HP Standard Instrument Control Library 
(SICL). The C program reads and forwards HP3852A scan commands from Oracle. Scanned data is read 
back from the instruments and inserted into Oracle tables. 

SCADA to M2000: Chamber contamination data is acquired by three QCM Research model M2000 data 
acquisition systems. The M2000 is directly connected to SCADA by a built in RS-232 interface. A custom 
SCADA driver controls M2000 operation and data collection. The driver functions by mapping SCADA 
real time database elements or tags to M2000 commands. The driver supports all M2000 modes of 
operation including calibration, operation and setup. Local control of the M2000 is performed through a 
SCADA software interface. Remote control of the M2000 is performed by an Oracle automation interface. 
The Oracle automation interface supports TQCM temperature control and criteria calculations. This 
functionality permits the unattended operation of facility bakeouts. 

SCADA to ORACLE: The SCADA to ORACLE interface is the mechanism used for logging data collected 
by PLC’s, HP3852A’s, M2000’s and future auxiliary systems. A custom C language SCADA program 
processes the data. The program was developed using the ORACLE Objects C Library. The Oracle library 
provides the hooks to write embedded SQL with C. This interface is faster, more flexible and lower cost 
than the Factory Link native Oracle interface. 

PowerBuilder Interface 

The Human Machine Interface is the “front-end” system that provides access to all measured test data. The 
use of PowerBuilder for the human machine interface allows for a Windows based client/server application 
that connects to the Oracle Database Engine. PowerBuilder applications are developed using PowerScript, 
an object oriented programming language that lets the developer dynamically control objects throughout 
the application. Techniques such as encapsulation, polymorphism and inheritance, which object oriented 
programming provides, allow for efficient, powerful and reusable code. The interface is run from an 
executable file residing on each computer or client. By running the application from each client, the server 
can be used exclusively for writing and retrieving data. 

The interface is designed so that each chamber may be monitored from any computer at any time. Each 
computer independently retrieves data from the database tables. This allows for unique custom display 
editing of the same test for every computer. By reading data points for database tables instead of directly 
from the AID boards, the user can look at data at any point in time, either as it is acquired or from hours or 
days past. The Oracle database is broken up into a series of tables based on each facility. This was done for 
two reasons. By limiting tables to hold data specific to a facility the size of the tables may be smaller and 



easier to maintain, and it allows for a faster retrieval of data. Due to the large volumes of data that are 
involved in thermal vacuum testing, the speed of data retrieval is very important. 

The presentation of data within the application can be customized both before and during the test without 
interrupting incoming data or other computer displays. Options available to the operator include activating 
or deactivating measuring devices or tags, setting alarms for any tag, configuring and monitoring multiple 
TQCM devices, creating and editing averages and gradients dynamically, access to tag libraries and 
printouts of all relevant data and test information. Data can also be saved and exported to a variety of file 
types including Plain Text, Microsoft Excel and Data Interchange format. 

Data can be visualized in two formats: tabular and graphical. Both formats can present current test data as 
well as historical data from current or previous tests. By allowing the operator to customize each screen 
through simple screen editors, relevant data can be grouped together in any fashion so that tests can be 
monitored safely. The tabular data format displays measured test data on tab pages in columns. Each tab 
page can display up to 160 tags and up to 30 tab pages can be defined for each chamber. Data displayed in 
graphical or plot form is useful for monitoring trends during a test. Up to eight tags can be displayed on 
each plot and 30 plots can be defined for each chamber. 


CONCLUSION 

Implementation of the new control and data acquisition system at Goddard is leading to improved lab 
efficiency and flexibility. Experimenters now have the ability to view real-time as well as historical data in 
a variety of ways, all user customizable. In addition, facility operators now have improved access to all 
chamber data from any and all locations throughout the laboratory. 



